home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 3⁄9⁄90 / 0844-Re Model⁄View-Mar90 < prev    next >
Encoding:
Text File  |  1990-03-09  |  3.8 KB  |  88 lines  |  [TEXT/GEOL]
  1. Item    7275082                         8-March-90        07:22PST
  2.  
  3. From:   POWERUP.DEV                     Power Up Software,PRT
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.         WILSON6                         Wilson, Dave-Personal Concepts,VCA
  7.  
  8. Sub:    Re- Model/View
  9.  
  10. Attn:  MacApp.Tech$
  11. Attn: Wilson, Dave-Personal Concepts
  12. SentBy: James Plamondon
  13. Date   3/6/90
  14. Subject    Re- Model/View
  15. From   James Plamondon
  16. To Wilson, Dave-Personal Concepts
  17. CC  MacApp.Tech$
  18.  
  19. Reply to:  Re- Model/View
  20. Dave,
  21.  
  22. Thanks for your response.  Your suggestion hits pretty close to what I have in
  23. mind.  I'll stick with your example in the following discussion.
  24.  
  25. Let's assume that I have some kind of global dependency dictionary, and that
  26. in this dictionary two objects, Invoice and Summary (of classes
  27. TCustomerInvoiceView and TCustomerSummaryView, respectively) are noted as
  28. being dependent on an object (Customer) of class TCustomer.  (Thus, to use my
  29. terminology, Invoice and Summary are dependents of Customer, and Customer is a
  30. supporter of Invoice and Summary.)
  31.  
  32. Let's further assume that the following methods have been added to TObject:
  33.     PROCEDURE TObject.SupporterChanged(
  34.                         theSupporter:                TObject;
  35.                         theChange:                      LONGINT;
  36.                         theContext:                     Univ Handle);
  37.         { This method advises SELF that one of the objects it depends on,
  38. theSupporter, has
  39.            changed.  theChange is an indication of the kind of change (a la
  40. itsChoice in
  41.            DoChoice()), while theContext contains whatever information is
  42. appropriate to
  43.            a change of the kind indicated by theChange. }
  44.  
  45.     PROCEDURE TObject.NotifyDependents(
  46.                         theChange:                      LONGINT;
  47.                         theContext:                     Univ Handle);
  48.         { This method advises SELF that it should notify its dependents that
  49. it has changed in
  50.            some important way.  The nature of the change is indicated by
  51. theChange, and
  52.            theContext includes whatever additional information is necessary
  53. for changes of that
  54.            kind.  This routine will send each of its dependents the message
  55.            SupporterChanged(SELF, theChange, theContext). }
  56.  
  57. All of the Set<some field>() routines in TCustomer end with a call to
  58. TCustomer.NotifyDependents(<some value>, NIL).  This routine uses a CASE
  59. statement (yuck!) on theChange to fill out theContext as needed, and then
  60. calls INHERITED NotifyDependents(theChange, theContext), which in turn sends
  61. SupporterChanged() messages to each of the TCustomer's dependents.
  62.  
  63. Each class that cares about SupporterChanged() messages will have to override
  64. SupporterChanged(), to take appropriate action.  This will again require a
  65. CASE statement on theChange, to find out what happened to theSupporter (and
  66. how to decipher theContext).
  67.  
  68. This all seems like an exceedingly non-object-oriented way of doing things — I
  69. mean, it uses CASE statements, for Eiffel's sake (whoops — sorry; didn't mean
  70. to get religious on you).  It has been suggested that instead of passing an
  71. identifier and a handle, one could pass a class ID and a object handle — and
  72. assume that the object was of some subclass of a new class called TMessage.
  73. Then, you could call polymorphic methods on the given TMessage object (which
  74. would actually be an object belonging to a sub-class of TMessage).  That is
  75. supposed to help somehow, but I'm not entirely clear on how it would help.
  76.  
  77. So — the question!  Do you (or anybody else out there) have an object-oriented
  78. way of implementing change propagation, which does NOT violate the Rule of
  79. Model/View Separation — or can they explain to me how a TMessage class helps
  80. in change propagation?
  81.  
  82. Looking forward to your responses, I remain,
  83.  
  84. Yours,
  85.  
  86. James Plamondon
  87.  
  88.